I've put a test site up at http://redesign.apis.dev.openstreetmap.org/ though note that it's a bit slow at the moment due to network issues at the hosting site.

Is the plan to do this as one large pull or as independent pulls?
I'm wondering because there's duplication between this and #456.

Also, do you want broad-level feedback, or specific issues like the 1px gap in

Looks great.

Probably the most significant issue to my eyes is content width on large screens: at (say) 1100px, /welcome looks pretty uncomfortable, and could maybe work better as a centred 700px column.

Couple of little details on browsing around:

• Logo and accompanying text aren't clickable - should just return you to / .
• P2 works great without sidebar. No need to reinstate it.
• Edit is better in 2nd tab position, I think: this reflects its importance and is more consistent with Wikipedia (and existing behaviour).

Suggestions:

• make left panel resizable, it is to big for me
• top panel is to big for me (I really want to max map size, especially the hight, with modern widescreens)
• logo could be bigger and should be clickable
• agree with richard, Edit should remain 2nd
• export vs share seems to be an issue for me, requesting a PNG also is an export to a "normal" user who doesn't distinguish between map (rendering) and data

In Safari 7.0 on Mac OS X 10.9 when making the browser window width small causes the header text to overlap.

Narrower:

And even narrower:

Ah, now I see it's on the todo.

Is the plan to do this as one large pull or as independent pulls? I'm wondering because there's duplication between this and #456.

If #456 gets merged separately I'll rebase this. The rest will probably be one pull.

Also, do you want broad-level feedback, or specific issues

Right now, broad-level and missing/broken functionality, so I can complete the TODO. Wait a bit for cosmetic issues.

Will there be a way to "close" the search result view (or history, export or data view)? What is the disabled x button on the "welcome" sidebar doing?

Enable then disable the data layer: the sidebar still displays "data". Alas, no objects are displayed: it seems like the data layer is broken.
(opera 12.16, windows 7)

Others have pointed out the problem of the topbar on small screens / windows not fiting horizontaly.

But I find that the extra vertical space wastes valuable space, clashes with iD (or is there a pull request pending for iD too ?), and is simply not as good loking as the original. I'm not sure either what is the criteria for buttonizing some links and not others; I'd be happy with no button in sight.

I like seeing "Help" and "User Diaries" in there, but I'm not so sure about "GPS Traces" and "About" being at such a prominent place. They're just not visited often enough (IMHO, but our sysadmins may have the stats) to warrant this position on the page.

Which brings me to the sidebar... It has been emptied of most of its content and made larger at the same time. It's great to use it for search results, a welcome improvement. But to me it could still be used for the old content, such as "about".

Also, displaying search result hides the "make donation", "where am I" and other items from the sidebar, without a visible way to get back to the original. I suggest that displaying search results be done in a dedicated part of the sidebar, without disturbing the rest of the content.

Some points:

• Menus could be collapsed in lists with narrow viewports.
• I'm not convinced with the export tab, in Reorganize export/share UI #351 you said " The OSM XML "Export" option remains, but no longer needs the prominence of a top bar tab,"
• Help tab could have a similar appearance to the About tab (including different background pics)
• Could you upload some traces to see http://redesign.apis.dev.openstreetmap.org/traces I opened Trace display on map #387 and I don't know if you considered also that section :-)

@sabas this pull would not be an appropriate place to add major new features like #387 so I very much doubt it will have been addressed.

I too would like to see traces display on the map, but that needs to be a separate change. This one is already too big. :)

Regarding "Export" and other navigation elements -- I think they're the best choice for now. The organizing rationale is that "View", "History", and "Export" all have a "primary" feel based on a common sidebar+map layout, and "GPS Traces", "User Diaries", etc have a content-only layout and "secondary" feel, so grouping them that way in the header makes sense. Eventually I do think we'll need to develop more of an information hierarchy around higher-level concepts like "Data" and "Community", and nest specific pages like "Export" and "History" underneath. A map-based "GPS Traces" page would fit better that way too. But for now, the design is intentionally closer to the existing organization, so that we can actually accomplish some incremental change.

Given how much this changes the navigation menus, a responsive small screen design will necessarily be a part of it -- that's on the TODO list.

It might be worth splitting this PR into multiple ones. At least separate the new sidebar behavior (collapsible and containing the search results) from changing the links locations and styling. I think the former is less controversial than the later, and could be merged more easily ?

Concerning the sidebar, I still see no way to get back to the previous state after having searched for something or closed the sidebar. Beyond having the search result not completely replacing the original sidebar content, I'm not sure what a good UI would be.

Some thoughts:

• Nav items on the right look like disabled to me... Maybe increase the contrast a bit?
• No close button on search results page (and way to get back to default welcome sidebar)
• No intuitive way to bring back the sidebar after you closed it

I use the changeset views more than most people probably do, so I'm going to start there

Issues

• On the changeset view the text "page 1" and "Changeset XML" is butted right up against the edge of the browser window
• There is no obvious way to go from one changeset by a user to the next/previous changeset by that user
• There is no obvious way to view all changesets from a user
• Can we bring more prominence to the changeset comment, if the changeset has one. In the same way that name=* is the name of an object, comment=* is the "name" of the changeset.
• There is a lot of vertical whitespace between sections, with whitespace, a line, and then more whitespace, also with a good amount of whitespace after section headings.

Questions

• How well will the changeset display work on large information-heavy changesets? To-do: Import some data into this API.

This has been merged - note that I rewrote the branch to fix @edenh's email address so the hashes will all be different.

It hasn't been deployed yet - will probably wait until the weekend to let people get started on translations. Have pinged Siebrand about getting Translatewiki updated.

(I'm assuming that what I'm seeing on the api06 server is what is intended to be deployed)

Changeset display draws attention to table information that tends not to vary ("created_by" etc.) and not to the information that does (comments, relations, ways, nodes).

Here's the a new one:

http://api06.dev.openstreetmap.org/changeset/35139

and here's what the site does now:

http://www.openstreetmap.org/browse/changeset/18722658

(actually, more readable still was the previous version of "changeset display" which displayed just the important information without the extra "pretty" cruft).

BTW - I was amused to see the "just a list of numbers" comment about the list of nodes higher up in this list. That's exactly what a changeset is, and that's the information that's useful!

@SomeoneElseOSM the "numbers" may be what the changeset is about, but what does know that a changeset contains node 3452353456 actually tell you? do you remember the IDs of all the nodes you are interested in?

@tomhughes If you're reviewing changesets by new mappers, the number tells you whether it was an old node that's been changed in some way or one that's been newly created and perhaps edited a couple of times.

I tried in the changeset page provided by @SomeoneElseOSM, if I click on the changeset object the geometry highlight doesn't load (bbox for changeset, line for way, circle for node).
Probably it's related to this request error onto the console (click on one object in the list)

GET http://api06.dev.openstreetmap.org/api/0.6/way/NaN/full 404 (Not Found)

I agree that not enough attention is drawn to a changeset comment. Maybe it should be emphasized somehow.

... and another comment on the "welcome" screen. Here's what I see with browser font sizes set the way that they normally are for me. "Welcome" is way too big and there seems to be no way of getting rid of it if you haven't signed up, and the layer display is bigger than the height of the screen. The latter may be something best dealt with in a future revision - would it be possible to not display the graphical stuff in the layer menu if it doesn't fit on the screen?

Look people, you've had weeks to comment on this. It's merged now, and commenting more here is not going to achieve anything.

@sabas thanks for spotting that - have pushed a fix in 37baed2.

@tomhughes:

Look people, you've had weeks to comment on this. It's merged now, and commenting more here is not going
to achieve anything.

Most people have only become aware of the changes now that you pushed them to production.

I must say I'm really unhappy with the new history browser. The old one just worked. The new one:

• doesn't provide a decent way to get the history of a bbox like the old http://www.openstreetmap.org/browse/changesets?bbox=16.1658%2C48.1165%2C16.5386%2C48.3048 – that now redirects to http://www.openstreetmap.org/history?bbox=16.1658%2C48.1165%2C16.5386%2C48.3048 , but see for yourself how that looks, and it also doesn't show the map frame. (When the redesign was originally pushed, it redirected to a view that had both frames, but that was not of the same bbox. So at least it does something decent now, but it is ugly.)
• in Konqueror/KHTML, has several issues, in particular:
  • lockups with 100% CPU consumption under some conditions I haven't yet figured out exactly.
  • the map view on the right never shows what it should. E.g., clicking on a changeset does not update the map view accordingly.
  • various glitches when trying to interact with the map while the history is open.
• even in Konqueror/KWebKitPart (which uses QtWebKit, so should be fairly standard), does not correctly react to the back button. In particular, the map view displays the wrong area after hitting Back.

All these things were working perfectly in the old history viewer.